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A SYSTEM AND METHOD FOR MANAGING 
CLIENT PROCESSES 



Background Information 

Computer hardware and software have been developed with the abihty to multitask to increase 
the effectiveness and efficiency of work that is performed on computing devices, for example, 
personal computers ("PCs") or servers. Such multitasking may be carried out by a single 
processor in a single PC, where the single processor simultaneously executes instructions from 
muhiple software programs. For example, a user of the PC may open a software program for the 
rendering of a drawing. While the software program is rendering the drawing, the user may have 
also opened a word processing program and started to type into a document. The processor of 
the PC may switch from processing the keystrokes of the word processing program to the 
rendering of the drawing in the intervals between keystrokes. Even though these intervals are 
quite short in terms of human time, these intervals may be quite lengthy for the processor of the 
PC. Thus, intervals during the execution of a primary operation such as these may be used to 
accomplish a secondary purpose, e.g., rendering the drawing. This is a very simple example of 
multitasking and the hardware and software mechanisms to implement a multitasking scheme for 
such a simple example may be very complex, requiring steps such as the prioritizing of tasks and 
the allocation of processor resources. 

More complex examples of multitasking arise in situations where there is a computer network 
arranged in a client-server relationship. For example, the server may have multiple processors 
with each processor processing separate tasks while receiving requests from clients on the 
network. The clients may be, for example, PCs, printers, modems, etc, which require services 
from one of the server processors in order to run various tasks, hi this type of environment, 
hundreds of chents may be simultaneously requesting services from the server. A process for 
implementing multitasking in such an environment must be extremely complicated to efficiently 
arrange and process each of the requests. Generally, multitasking has positive connotations 
because of the improved efficiency associated with the ability to perform more than one process 
at one time. 
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However, multitasking has finite limitations because it is dependent on various factors such as 
the operating characteristics of the processor(s), memory, and I/O devices. For example, if a 
processor in a server is performing tasks for several clients, and the resources of that processor 
are being completely utilized, the processor can no longer multitask a new client request because 
of insufficient processor resources. Furthermore, a requested chent task may be invalid 
preventing the server processor from effectively processing the task. In this situation the 
processor may continue to process the task without ever finishing because of the problem with 
the task, e.g., improper coding of the task resulting in an endless processing loop. A processor 
that is caught in an endless loop cannot be released to process other tasks. The processor may 
then simply crash and, in any case, needs to be restarted. Li either case, the advantages of 
multitasking are not achieved. 

Summary of the Invention 

A system for managing a plurality of client processes, comprising a chent task within which the 
client processes will be executed and a manager task running at a higher priority than the client 
task, the manager task queuing the client processes into the client task in priority order, wherein 
the manager task kills the chent task when a current one of the client processes is not completed 
within a predetermined time period. 

Brief Description of Drawm2s 

Fig. 1 shows an exemplary network on which the present invention maybe implemented. 

Fig. 2 shows an example of multiple processes being simultaneously run on a processor. 

Fig. 3 shows an exemplary manager task and client task managing the execution of a chent 
process on a processor according to the present invention 

Fig. 4 shows an exemplary manager task and client task managing the execution of client 
processes in a processor according to the present invention. 
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Fig. 5 shows an exemplary control process for the manager task according to the present 
invention 

Fig. 6 shows an exemplary control process for the cUent task according to the present invention. 

5 

Detailed Descriptioa 

The present invention may be further understood with reference to the following description and 
the appended drawings, wherein like elements are provided with the same reference numerals. 
Mitially referring to Fig. 1 there is illustrated an exemplary network 1 on which the present 
10 invention maybe implemented. Network 1 includes six network segments 10-60 each of which 
has a network bus 1 1-61 to which various network devices are connected. Network segment 10 
has server 15 connected to bus 11. Network segment 20 has printers 25-26 connected to bus 21, 
€l Network segment 30 has personal computers (PCs) 35-36 connected to bus 3 1 . Similarly, 
iji network segments 40-60 have PCs connected to their buses, hi the exemplary network 1 of Fig. 
§5 1 , all of network segments 10-60 are linked via ports of network switch 70 allowing each of the 
03 network hardware devices to interconnect with any or all of the other hardware devices on any of 
r network segments 10-60. hi this exemplary embodiment of network 1, the network arrangement 

t^, is that of a chent-server relationship. Server 15 is the server and all the other hardware devices 

are clients. Server 15 may have functions which serve all the other hardware devices on the 
|i) network, for example, file sharing, printer queues, etc. hi such an arrangement, the processor or 
'''' processors of server 1 5 may have to multitask to most efficiently use the resources of server 1 5 to 
serve the other hardware devices. Those skilled in the art will understand that network 1 is only 
one exemplary system on which the present invention may be implemented and that the present 
invention is applicable to any computing device where muUiple processes or procedures may be 
25 run on a microprocessor. For example, the present invention may be implemented on any one of 
the PCs connected to network 1 of Fig. 1 or on a PC which is not connected to any network. 

Fig. 2 shows an example of multiple processes 1 10 and 120 being simultaneously run on 
processor 100. hi Fig. 2., process PI 1 10 and process P2 120 need to be executed by processor 
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100. In this example, process PI 1 10 has a higher priority than process P2 120, which means that 
when process P 1 1 1 0 is ready to execute, processor 100 will execute process PI 1 10. Process P2 
120 may be executing on processor 100 when process PI 1 10 is ready to execute, but since 
process PI 1 10 has a higher priority, it will preempt process P2 120. If for some reason, the 
5 execution of process P 1 1 1 0 is interrupted for some reason {e.g. , process P 1 1 1 0 may need access 
to a system resource such as disk I/O that is presently unavailable to processor 100), process P2 
120 maybegin to be executed by processor 100. However, once process PI llOis abletobe 
executed, it will preempt the execution of process P2 120. 

1 0 Fig. 3 shows an exemplary manager task 1 50 and chent task 1 60 managing the execution of 

cUent process 170 on processor 100 according to the present invention. Client process 170 may 
p be any process that needs to be executed by processor 100, for example, process PI 1 10 and 
:fl process P2 120 Fig. 2. In this case, client process 170 is the actual process that processor 100 
W executes to accomplish a goal set by the user. The user may write software code in order that the 
if computing device may accomplish different processes, for example, reading from or writing to a 
^ ! device, assembling a network protocol, etc. Chent process 170 may execute within client task 
^ 1 60. It should be noted that a process and a task may be considered to be the same, i.e. , lines of 

h software code that may be executed by processor 1 00. hi this description, the terms process and 
L-- task are used to describe such lines of software code, but the term task (e.g. , manager task 1 50 
pb and chent task 1 60) is used to define an element of the present invention that work in conjunction 
to manage the execution of user processes. Thus, the term process is used in this description to 
refer to any lines of software code that a user may desire to execute to accomphsh a goal. These 
processes may be considered to be third party software code that is completely separate from the 
code that implements manager task 150 and chent task 160. Additionally, manager task 150 and 
25 chent task 1 60 are generic and may be used to manage the execution of any user processes. 
Since client task 160 is generic, cUent process 170 maybe queued into chent task 160 for 
execution by processor 100. The details of this process will be described in greater detail below. 
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As described above, manager task 150 and client task 160 will manage the execution of client 
process 170 on processor 100. Manager task 150 will execute as a higher priority process than 
chent task 160, The reason for manager task 150 having a higher priority than cUent task 160 
will be described in greater detail below. Manager task 1 50 and cUent task 1 60 may be 
considered processor management tools that prevent chent process 170 from interfering with the 
execution of other chent processes (not shown). As described above, an issue may arise if 
processor 100 cannot complete execution of cUent process 170. Processor 100 may end up in a 
continuous loop where it never completes executing client process 170, and therefore, other 
processes waiting to be executed by processor 100 may not be executed. 

This is not an acceptable outcome in high availability applications where it is important that the 
system (e.g., the processor) be continuously available. In order for processor 100 to be 
continuously available, manager task 150 and client task 160 provide a mechanism to monitor 
chent processes, for example, client process 170, to ensure that an errant client process does not 
deteriorate the availability of processor 100. Manager task 150 oversees the execution of client 
process 170 within client task 160 to ensure that such an issue does not arise in processor 100. 
As described above, both manager task 150 and client task 160 are generic and any client process 
may execute within the generic client task 160 and manager task 150 may oversee the execution 
of any chent process. The basic interaction between manager task 150, chent task 160 and chent 
process 170 is that during the execution of chent process 170, manager task 150 would expect a 
response from chent task 160 to indicate that client process 170 is executing properly. This 
indication maybe, for example, that chent process 170 is complete, that chent process 170 has 
output some intermediate value, etc, hi the event that manager task 150 has not received the 
proper indication within a predetermined period of time, manager task 150 may kill the execution 
of chent process 170 within processor 100 by restarting chent task 160. Since chent process 170 
is queued within client task 170, this restart kills the execution of chent process 170. Upon 
restart of chent task 160, manager task 150 may then queue the next client process (not shown) 
into chent task 160 so that it maybe executed by processor 100. 
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Fig. 4 shows manager task 200 and client task 210 managing the execution of client processes 
220-240 in processor 100 according to the present invention. If client process 220 is improperly 
coded, it may, for example, enter a continuous loop and therefore, chent task 210 may not send a 
proper indication to manager task 200. hi this case, manager task 200, because it is operating at a 
higher priority than client task 210 may instruct processor 100 to restart client task 210, thereby 
killing the execution of client process 220. When chent task 210 is restarted it may be queued 
with a new client process, for example, chent process 230, for execution by processor 100. hi 
this case, client process 230 will then be executed by processor 100 and manager task 200 will 
expect an indication from cUent task 210 that client process 230 is operatmg correctly. When 
cUent process 230 is complete, chent task 210 will mdicate that client process 230 is complete to 
manager task 200 and the next client task 240 will be queued and executed within client task 
210. 

Fig. 5 shows an exemplary control process for manager task 300 according to the present 
invention, hi step 310, manager process 300 initiahzes binary semaphores "y" and "z" as empty 
or not available. A semaphore is a hardware or software flag, hi multitasking systems, a 
semaphore is a variable with a value that indicates the status of a common resource. It is used to 
lock the resource that is being used. A process needing the resource checks the semaphore to 
determme the status of the resource and then decides how to proceed, hi this case, manager task 
300, in step 310, has locked semaphores "y" and "z" so that any other process that needs these 
semaphores to execute cannot do so until they are released. The process then continues to step 
320 where manager task queues a chent process, for example, chent process 220 in Fig. 4. The 
queuing of the chent process moves it into the chent task so that the chent process may be 
executed by the processor. However, the client task is not ready to run and execute the chent 
process at this time because it needs one of the semaphores hi order to run. The process then 
contmues to step 330 where manager task 300 releases semaphore "y" to the chent task. 
Semaphore "y" is expected by the client task so that it may begm to run. An exemplary process 
for the client task will be described in greater detail below. After manager task 300 releases the 
semaphore "y" to the chent task, the process continues to step 340 where manager task 300 
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blocks on semaphore "z" to allow the client task to run. Manager task 300 will block on 
semaphore "z" for a predetermined timeout period. As described above, manager task 300 is 
expecting some action by the client task within the predetermined timeout period. The 
consequences of this timeout period will be described in greater detail below with respect to step 

5 350 of manager task 300. Continuing with step 340, to block means that the task is not 

scheduable or executable by the processor meaning that manager task 300 is no longer allowed to 
continue executing. The reason that manager task 300 must block is that since it is running at a 
higher priority than the client task, the client task cannot run because manager task 300 will 
preempt its execution. However, once manager task 300 is blocked, the chent task may begin to 

1 0 execute. Before completing the process of manager task 300, this description will continue with 
an exemplary process for the chent task because when manager task 300 is blocked the chent 
task may begin to execute. 

y Fig. 6 shows an exemplary control process for client task 400 according to the present invention. 
t$ In step 41 0, it is determined whether semaphore "y" has been released to chent task 400. Until 
S semaphore "y" is released, chent task 400 cannot run because it is waiting for semaphore "y" to 
r be set as usable by chent task 400 so it can begin executing the client process. If semaphore 
m has not been released, the process continues to loop within step 410 until semaphore "y" is 
^; released. Those skilled m the art wiU understand that chent task 400 is dependent upon access to 
ij) semaphore "y" to run and that chent task 400 will also not run until manager task 300 is blocked 
because manager task 300 has a higher priority than client task 400. 

When semaphore "y" is available, chent task 400 takes semaphore "y" in sep 420 and the process 
continues to step 430 where the chent process is executed by the processor. The client process is 
25 queued by manager task 300 into chent task 400 for execution by the processor. When the chent 
process has been executed in step 430, the process continues to step 440 where the semaphore 
"z" is released to manager task 300. Semaphore "z" is the indication that manager task 300 is 
awaiting to ensure that the chent process is running properly on the processor. This indication 
maybe that the chent process is complete or that the chent process has given some intermediate 
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output, etc. Those skilled in the art will understand that if client task 400 will be giving an 
indication of intermediate steps of the execution of a client process to manager task 300, it may 
be possible that more semaphores will be used to indicate flirther intermediate steps as well as 
completion of the execution of the process. For example, if chent task 400 will be indicating to 
5 manager task 300 when a chent process is at a midpoint and when it is complete, two semaphores 
may be used, or a single semaphore with two timeout periods may be used. Client task 400 may 
never complete the execution of the client process in step 430 because there is a problem with the 
chent process, e.g., improper software codmg by the user, hi this case, chent task 400 will 
remain in step 430 until it is restarted by manager task 300. If, cHent task 400 remains in step 
10 430, it will not proceed to step 440 where semaphore "z" is released, and therefore, manager task 
300 will not see the proper indication (e.g., the release of semaphore "z" within the timeout 
period) that the chent process is executing correctly, hi this case, chent task 400 will be 
restarted by manager task 300 and the current client process will be killed. When client task 400 
yj is in step 430 and it is restarted by manager task 300, it restarts at step 410. However, if the 
ft process completes execution of the client process in step 430 and semaphore "z" is released m a 
ffl timely fashion in step 440, the process loops back to step 41 0 to await the release of semaphore 
= "y" so that chent task 400 may execute the next queued client process. 

Referring back to Fig. 5 to continue with the exemplary process for manager task 300 at step 350 
if) where it is determined whether semaphore "z" has been released by chent task 400 before the 

timeout period has expired. Manager task 300 begins to execute on the processor again because 
it is only blocked until semaphore "z" is released or until the timeout period has expired. Since 
manager task 300 runs at a higher priority than chent task 400, when the timeout period expires 
and manager task 300 is ready to run again, the processor will continue with the execution of 
25 manager task 300 by preempting the execution of client task 400. If semaphore "z" has been 
released within the timeout period, this means that the chent process queued within client task 
400 has been successfully executed. The process may then loop back to step 320 to queue the 
next client process that can be loaded uito client task 400 to be executed by the processor. 
However, if semaphore "z" is not returned in a timely manner to manager task 300 in step 350, 
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the process continues to step 360 where manager task 300 takes semaphore "y" and marks it as 
unavailable. This process is similar to the initialization of step 310 to make sure that any other 
tasks or processes that need semaphore "y" will be blocked. Manager task 300 then proceeds to 
step 370 where it restarts chent task 400, thereby kilhng the currently executing client process. 
The process may then loop back to step 320 and the next chent process maybe loaded into client 
task 400 to be executed by the processor. When client task 400 is restarted in step 370, the chent 
process that is causing the problem (e.g., a chent process that is improperly coded resulting in the 
processor being in continuous loop and not allowing the client process to complete within the 
specified time period), is removed fi-om the queue of chent task 400. Thus, when client task 400 
is restarted in step 370, there are no pending chent processes in its queue, client task 400 is 
waiting for manager task 300 to queue up the next client process and release semaphore "y' 

Referring back to Fig. 4, an ahemative embodiment of the present invention will be described, 
hi this alternative embodiment, if client process 220 that is currently being executed by processor 
100 does not complete execution within the time period specified by manager task 200, client 
task 210 is still restarted, thereby kilhng chent process 220 as described above. However, client 
process 220 is given at least one fiirther chance to be executed by processor 100. When client 
task 210 is restarted by manager task 200, the unexecuted client process 220 is requeued by 
manager task 200. If chent process 220 remains the highest priority client process, manager task 
200 will move client process back into chent task 210 so that processor 100 may begin to execute 
client process 220. If the problem that caused client process 220 to not be completed has been 
resolved, client process 220 will be completed and an indication of this completion will be sent 
to manager task 200. In the event that client process 220 again does not complete, manager task 
200 may, once again, requeue client process 220 or it may queue the next client process, for 
example, chent process 230, because chent process 220 is damaged and may never execute 
properly. In the event that processor 100 unsuccessfully attempts to execute client process 220 
several times, manager task 200 will not requeue client process 220 and then the next highest 
priority process, for example, chent process 230, may be queued into chent task 210 for 
execution by processor 100. The number of times that a client process can be retried may be 
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settable by the user. 



In the preceding specification, the present invention has been described with reference to specific 
exemplary embodiments thereof It will, however, be evident that various modifications and 
changes may be made thereunto without departing from the broadest spirit and scope of the 
present invention as set forth in the claims that follow. The specification and drawings are 
accordingly to be regarded in an illustrative rather than restrictive sense. 
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